@adrianhoelzl-sap Makes sense overall, thanks!
I tried and saw that for lines like this one:

If you narrow it to just IntegrationTestUtils.createGroup (aka do not ignore conflicts but still expect HttpStatus.CREATED), the tests will still be passing. Why ignore? Maybe we should use the more strict check (expect HttpStatus.CREATED only)?

@adrianhoelzl-sap Makes sense overall, thanks! I tried and saw that for lines like this one:

uaa/uaa/src/test/java/org/cloudfoundry/identity/uaa/integration/feature/SamlLoginIT.java

Line 162 in bdec670

IntegrationTestUtils.createGroupAndIgnoreConflict(token, "", baseUrl, group);

If you narrow it to just IntegrationTestUtils.createGroup (aka do not ignore conflicts but still expect HttpStatus.CREATED), the tests will still be passing. Why ignore? Maybe we should use the more strict check (expect HttpStatus.CREATED only)?

For me, the tests fail because the groups already exist, maybe they are created already by previous tests. You can see the error messages in the voters for commit c51ed9f.
IMO, it is fine to accept the conflict status code here, since we just want to ensure that the groups are present. If they already are, we can ignore the error.

@adrianhoelzl-sap Makes sense overall, thanks! I tried and saw that for lines like this one:

uaa/uaa/src/test/java/org/cloudfoundry/identity/uaa/integration/feature/SamlLoginIT.java

Line 162 in bdec670

IntegrationTestUtils.createGroupAndIgnoreConflict(token, "", baseUrl, group);

If you narrow it to just IntegrationTestUtils.createGroup (aka do not ignore conflicts but still expect HttpStatus.CREATED), the tests will still be passing. Why ignore? Maybe we should use the more strict check (expect HttpStatus.CREATED only)?

@peterhaochen47 I made the behavior of the createGroup calls in SamlLoginIT more explicit by adding a method ensureGroupExists and removing the createGroupAndIgnoreConflict method (commit 7fc64b2).